The Peripheral Component Interface (PCI) is fast becoming a preferred interface for input/output functions in computer-related apparatus. The PCI Local Bus Specification is an industry standard which provides details regarding signal levels, protocols and circuit configurations for interconnecting external devices to existing internal bus structures in data processing equipment. See PCI Local Bus Specification, Revision 2.1 (Jun. 1, 1995) incorporated in full herein by reference.
The PCI interface is generally implemented to interconnect an application on a host computer to an external device or communication apparatus. Typically, an input/output (I/O) card interconnects with the host as an "accessory" to the host, and the PCI specification provides a mechanism for interconnecting the I/O card and host. The I/O card carries memory that is used to communicate with the host and is at least in part accessible to the processor(s) of the host (i.e., a common memory space on the card is shared between the host and card).
A common mechanism for allowing the host and accessory to exchange information uses shared memory that can be read and written by both processors (one processor on the host and one on the accessory) and, additionally, uses interrupt registers that: (i) allow both processors to post an interrupt to each other, (ii) determine if the other processor has posted an interrupt, and (iii) clear a posted interrupt. When this mechanism is used with the PCI local bus, the shared memory and interrupt registers (used by the host) are part of the accessory resources which are made available to the host.
To facilitate the interconnect between the host and accessory, PCI provides a mechanism for allowing the host to determine what type of accessory is installed by using the specially designated Register Class Code and/or Device ID fields in the PCI Configuration Space. These features are fully described in the PCI specification. However, this PCI mechanism of identifying installed accessories is not very flexible because the host application must be designed in a manner such that it has complete prior knowledge of the location of resources (i.e., memory registers) that the accessory makes available to the host. For example, the "IDE" controller class is used by devices that comply with the PCI IDE controller specification which completely describes the register level programming interface that must be followed. Simply stated, the host must have a prior knowledge of the register assignment before it can use the accessory, and the host must know the address arrangement of the accessory resources in the common memory space.
The PCI local bus specification also defines a mechanism for mapping a block of accessory based resources into the host microprocessor's memory space. However, the location of each resource within the block is fixed by the accessory designer.
FIG. 1 is a block diagram of an exemplary PCI Configuration Address Space 10 and PCI Memory Address Space 15 for an accessory. PCI Configuration Address Space 10 includes Configuration Space Registers 20, of which only Base Address Register 0 is shown (identified with reference number 25). Base Address Register 0 holds a value that points to the area of common memory in the PCI Memory Address Space 15 where the Accessory Based Resources 30 reside. In the example shown, four memory registers (resources) are depicted within Accessory Based Resources 30 and denoted as Card Register Block 35, Interrupt Status Register 40, Interrupt Clear Register 45, and Interrupt Set Register 50. Note, however, that there is no indication of where the four resources actually are located in the Accessory Based Resources 30 memory space. This is because, as conventional in the art, the resources are FIXED based upon the type and design of accessory installed. Namely, the physical address locations of these resources are fixed based on arbitrary design criteria for the accessory. Accordingly, this resource address information must be known in advance by the host in order to access the registers and utilize the accessory correctly.
Where the host is a general purpose computer as has been conventional in the art, such advance knowledge of accessory resources has typically not been a problem. This is because the developer (or manufacturer) of the accessory generally develops a device driver that executes on the host to interface with the accessory. The developer hard codes the accessory resource information into the device driver. In the event the accessory is modified, the developer simply updates its device driver and distributes it to the user for reloading on the host. Similarly, if the developer desires the device driver to be compatible with other accessories, then the known fixed resources are determined for those other accessories and hard coded into the device driver and then distributed for update to the user. Thus, updating a device driver on a general purpose host computer for a specific accessory or accessories has not been uncommon.
Lately, however, the PCI local bus interface has been used not only to interconnect host computers with their accessories, but also peripheral devices with their accessories. For example, some printer devices use PCI to interface the printer with its accessories (such as disk drives or network cards within the printer). In this context, the peripheral (i.e., printer) is the host for the accessory and, again, the prior art requires that the peripheral know the predefined resource configuration of the accessory in order to properly use the accessory. However, disadvantageously, this presents more of a problem in the peripheral-accessory context than in the general purpose host computer-accessory context because the peripheral is not a general purpose computer. Rather, the peripheral has a predefined and limited capability.
Typically, peripherals are not designed to accommodate the loading of updated device drivers that know an accessory's configuration. Rather, the accessory's configuration must be hard coded into the peripheral's own operating system so that the peripheral will know the address arrangement of each accessory based resource before operation. For example, the peripheral must use its own internal driver in order to be able to: (i) identify each accessory's revision, and (ii) use that accessory. This requires multiple firmware segments to work with the potentially various accessory versions. As a result, peripheral code development can be long and complicated, and additional testing of code upgrades may also be required. All in all, in the event of a need to modify (upgrade) the accessory or expand the peripheral's compatibility with additional accessories, major steps must be taken to upgrade the peripheral's own operating system device drivers. This usually requires a peripheral firmware upgrade or the replacement of Read Only Memory (ROM) chips--both of which can be costly, time consuming and burdensome.
Accordingly, an object of the present invention is to enable an improved PCI local bus for a peripheral and its accessories.